One of the difficulties encountered with simulations of avionics systems is the diversity of their components (e.g. the pieces of equipment, also called “equipments” in the aviation domain), and the diversity of the data formats that need to be taken into account for simulation purposes.
Thus, the simulation must be a faithful representation of electrical functions and/or electronic functions and/or hydraulic functions and/or mechanical functions performed by this variety of components.
As for the data formats relating to these components, they may be of the analog type and/or discrete type and/or binary type and/or presented as structured data.
Thus, upstream from the simulation, data is available in various types, in particular raw data in avionics format.
However, only a digital abstraction of data in engineering data format is suitable for use in a simulation.
Such a digital abstraction must have a unitary format regardless of its origin, its units, its values, and its function. This unitary format for expressing data is representative of the raw data in avionics format.
To summarize, data in engineering format is the data “spoken” by models in pure simulation or that is manipulated internally in the models that are representative of pieces of equipment.
In contrast, upstream from these simulation models, the data is in avionics format. Data in avionics format is therefore representative of the system when on board the destination aircraft.
In order to be homogenous and compatible within the situation, the data in avionics format complies with the on-board data exchange protocol, while nevertheless being representative of real data. This must make it possible by encoding to translate the data into engineering format. The data in avionics format is retrieved by decoding.
In order to illustrate the complexity of such encoding/decoding, various types of avionics format data are mentioned below.
Thus, in order to measure temperature, i.e. information of a physical nature for incorporating in a simulation, the equipment generates data in avionics format in the form of an analog signal presenting some number of Volts.
The data in engineering format representing temperature in a measurement unit specific to the instrument that evaluates temperature is for example in degrees Fahrenheit. However, it may be necessary in the simulation for the data in engineering format to represent temperature values given in degrees Celsius. This involves additional conversion.
Other data in avionics format, such as an on/off control, is in the form of a discrete signal (e.g. on/nominal voltage/ground), associated with state values (0/1).
Furthermore, in conventional avionics protocols, data in avionics format is always in the form of n-bit words (often 32-bit words) containing a plurality of fields, or having a null state. Such words, which are used for describing functions, their physical media, and their electrical interfaces, are conventionally conveyed on a standard data bus.
Likewise, numerous modern avionics systems include components having one or more computers running software. Various subassemblies (e.g. partitions) are connected together by cabling, communications buses, and connectors.
The data specific to such computer components comes in a variety of structured data forms, as defined by the protocol to which it belongs.
It can thus be understood that this wide variety of data (in particular in avionics format) for transforming into data in engineering format, and conversely for retrieving from engineering format, gives rise at present to numerous technical problems.
Furthermore, for a given avionics system, it is common practice for a component computer to operate with a specific operating system (OS), commonly referred to as an “avionics” OS.
It is not rare for a plurality of avionics OSes to co-exist in the same avionics system, each of them being dedicated to a specific computer, for example.
In practice, these avionic OS' are different from the operating systems (Unix®, Linux®, Windows®) commonly employed in the workstations that are used for programming and/or testing and/or simulation of avionics systems.
The abstraction that enables data to be obtained (in particular in avionics format) for simulation of the avionics system must naturally be independent of such an operating system.
Another drawback at present is that the workstations used for simulations need to have processing capacity and a number of processors that are greater than the capacities and the number of processors in the avionics systems to be simulated.
Yet another drawback that is observed during simulation lies in the difficulty of incorporating changes in the avionics system and/or in its components.
Mention is now made of certain documents relating to real time simulation.
Document EP 0 807 882 describes a software interpreter for a multicard avionics computer. Several sets of program instructions are implemented on a workstation having processing capacity and a number of processors that are greater than the capacity and the number of processors of the avionics. With an operating system such as Unix, real time tasks are executed and cache memories and procedures are shared. A set of instructions and data representative of the avionics is loaded directly into a target memory simulation system. An example of the avionics concerned is the multifunction LAMPS MKIII on-board platform for an anti-submarine helicopter.
Document EP 1 944 663 describes simulating dynamic feedback control of a turbine for running on consumer electronics. Those simulations are used for acceptance testing purposes on physical pieces of equipment or hardware. Models of genuine programs are simulated after being translated to a destination environment. During simulation, the data associated with the model may be modified in part only. Prior to executing the simulation, commands that are typically in the C and C++ languages are modified using a graphics interface.
Document U.S. Pat. No. 4,845,665 describes the use of a workstation to develop programs for external interfaces in the form of display screens. In order to evaluate the ergonomics of a program before its code has been produced, it is possible to alter the interfaces in reversible manner while simulating the program. The changes that are observed are recorded on a disk. Tables and their formats are simulated.
Document U.S. Pat. No. 5,260,874 describes a flight emulation test system for application to an airliner on the ground. A road vehicle can be seen connected to a grounded airplane by means of removable cables in order to verify the proper operation of various essential mechanical and electrical components thereof. The emulation verifies that the components respond appropriately to the stresses applied by the test system.
Document U.S. Pat. No. 5,541,863 describes a virtual test bench with incorporated software for avionics. The test bench is reconfigurable and makes use of partial simulation together with genuine physical pieces of equipment. Graphics displays with multiple functions show information that may be provided to a screen of a workstation such as a DEC station under VMS, which data is presented in the form of graphics and tables. Line replaceable units (LRUs) are tested in real form or by replacing a simulation module on a test bench referred to as a “rack”. Numerous changes in the program being developed are made apparent. That bench makes it possible to test simulated on-board software or on-board software on an on-board computer without exhaustively simulating the physical interfaces of the pieces of equipment or modules. It is possible at will to test the operation of the simulated equipment or of the real equipment. Equipment simulation remains restricted to the functional portion.
Still in the field of numerical simulations, referred to as a virtual aircraft in the field of aviation, various protocols are used. These protocols contribute to integrated modular avionics (IMA).
Accordingly, it would be desirable to simulate protocols and enable them to be modified while they are being simulated. For example, it would be desirable to simulate the dedicated avionics protocols, such as: ARINC429, ARINC653, MIL-STD-1553B and protocols, standards, or languages in the general field of computing such as: RS422, Ethernet, extensible mark-up language (XML), C/C++.
All of these tools, languages, protocols, standards, and systems are conventionally described in publications that can easily be obtained, in particular over the Internet.
Wikipedia, the on-line encyclopedia, contains descriptions of the documents mentioned that may be compared with the invention.
As mentioned above, real time simulation of avionics systems at the present time gives rise to various technical problems, in particular when high representativity is required of the simulated avionics system.
For example, this applies when the simulation needs to incorporate a diversity of data streams coming from a radio altimeter and/or a sensor (e.g. a temperature sensor), and/or a gyroscope (also called a “gyro”).
In other words, it is difficult or even impossible in practice at the present time to obtain an abstraction, i.e. a “translation” or conversion, of these varied data streams in a manner that is simple.
For example, data in radians in engineering format needing to be translated into avionics protocol gives a voltage value that complies strictly with formally specified conversion tables.
As a result, it is particularly difficult with present-day simulations to represent faithfully the real architecture of an avionics system and/or to enable the system to be represented in part only.
Another problem that is presently encountered when simulating an avionics system is obtaining exhaustive and reliable definitions of the various components of the avionics system that it is desired to simulate. It is sometimes said that such definitions that are actually representative of reality are “consistent”.
This is true in particular for the interfaces between the components and/or their subassemblies (in particular the partitions of certain pieces of equipment). In other words, it is at present difficult to obtain definitions that are consistent and exhaustive of the avionics architecture of a system that is to be simulated.
Another problem is that it is presently difficult or even impossible in practice to play back on a mock-up data that is sufficiently reliable and easy to process for the purpose of qualifying (specifying) at least one of the pieces of equipment of the avionics system.
In particular, such qualification data must in itself constitute an acceptable basis that is recognized by competent authorities for type approval (like the incremental qualification known in the field of quality control).
Still another problem is to have a simulation environment that is flexible and reliable in order to monitor all of the simulation data (regardless of whether it is in engineering and/or avionics format).
Consequently, it would be useful to enable the behavior of the components of the avionics system and their interactions to be analyzed in a context representative of real operational conditions.
For example, a flexible simulation would make it possible to take account of operational tolerance ranges and/or to define and/or to evaluate acceptable operating margins for one or more components of the avionics system.
One of the additional problems presently encountered with test benches is that, in practice, it is difficult to perform tests of an avionics system if any of its essential components are unavailable and/or not operational.
As mentioned above, it is desirable to have a simulation available that is “mixed”.
This makes it possible to incorporate in the simulation, as and when they become available, validations from various actors involved in producing an aircraft (in particular people in charge of functions and/or avionics architects and/or in charge of flight testing and/or state services).
Thus, for each identified change in the avionics to be simulated, it should be possible to obtain perfect traceability and conformity of the corresponding simulation.
Furthermore, it is appropriate for the simulation to adapt to maintainability targets (in other words long life) that are imposed on avionics systems.
To this end, it is appropriate for the simulation to be capable of being generated at will so as to take account of each required change in the avionics system.
For example, the simulation platform must support the various generations of tools for generating avionics systems and/or must be compatible with the tools that are used in generating associated assemblies (functionally connected in order to make the aircraft operational). This applies particularly to the software environment.